На собеседованиях гоняют по теории, потому что не знают, что ещё спрашивать!
Как-то я прособеседовал 15 человек за неделю и понял, что соискатели сами виноваты в том, что их гоняют по дебрям теории и загадывают ребусы.
Смотрите, в чём дело.
Вот приходил чел писать высоконагруженный бэк. Мне нужно понять, насколько он хорош, поэтому я спрашиваю про опыт. Во-первых, пересказ Книги с Кабанчиком не гарантирует экспертности, а во-вторых конкретные случаи из практики соискателя дадут мне зацепки для дальнейшей беседы. Мы поговорим про технические решения, ограничения, зависимости всякие, и сразу станет понятно, насколько человек владеет мастерством.
Но обычно мало кто может внятно рассказать о своём опыте, разговор не клеится, оба сидят как дураки, и интервьювер тянется за списком типовых вопросов в духе «Назовите мне этапы инициализации контекста в спринге».
Как надо
Чтобы не тонуть на собеседовании, стоит говорить на знакомые вам темы. А для этого расскажите связную историю и расставьте триггеры в нужных местах, чтобы интервьювер спрашивал у вас то, что вы хотите рассказать. Например:
Я разработал архитектуру приложения, которое зарабатывало бизнесу 400к $ в месяц. Приложение интегрировалось с 7 разными глючными системами. Входная нагрузка была 100 rps, а мы генерировали в районе 500 rps к сторонним системам. Чтобы повысить надёжность, мы применяли асинхронную коммуникацию на кафке. А чтобы особенности интерфейсов этих систем не влияли на наш домен, мы использовали hexagonal architecture, вынеся всё взаимодействие в плагины.
Основные триггеры:
-
-
- Вдобавок тут огромное количество технических ништяков, которые нормальный интервьюер увидит, и вы проговорите про них оставшийся час:
- Hexagonal
- Асинхронная коммуникация
- Кафка та же самая
- Взаимодействие с нестабильными API
А в следующий раз я расскажу, как улучшить описание своих обязанностей, рассказывая о них через призму достижений
Как-то я прособеседовал 15 человек за неделю и понял, что соискатели сами виноваты в том, что их гоняют по дебрям теории и загадывают ребусы.
Смотрите, в чём дело.
Вот приходил чел писать высоконагруженный бэк. Мне нужно понять, насколько он хорош, поэтому я спрашиваю про опыт. Во-первых, пересказ Книги с Кабанчиком не гарантирует экспертности, а во-вторых конкретные случаи из практики соискателя дадут мне зацепки для дальнейшей беседы. Мы поговорим про технические решения, ограничения, зависимости всякие, и сразу станет понятно, насколько человек владеет мастерством.
Но обычно мало кто может внятно рассказать о своём опыте, разговор не клеится, оба сидят как дураки, и интервьювер тянется за списком типовых вопросов в духе «Назовите мне этапы инициализации контекста в спринге».
Как надо
Чтобы не тонуть на собеседовании, стоит говорить на знакомые вам темы. А для этого расскажите связную историю и расставьте триггеры в нужных местах, чтобы интервьювер спрашивал у вас то, что вы хотите рассказать. Например:
Я разработал архитектуру приложения, которое зарабатывало бизнесу 400к $ в месяц. Приложение интегрировалось с 7 разными глючными системами. Входная нагрузка была 100 rps, а мы генерировали в районе 500 rps к сторонним системам. Чтобы повысить надёжность, мы применяли асинхронную коммуникацию на кафке. А чтобы особенности интерфейсов этих систем не влияли на наш домен, мы использовали hexagonal architecture, вынеся всё взаимодействие в плагины.
Основные триггеры:
-
400к $ в месяц — вы сразу показали что не в игрушки игрались, а делали серьёзную систему, за простой которой начальство сильно спросит.-
100/500 rps — показали цифрами, что для вас высокая нагрузка, а не пресловутые «высоконагруженные системы».- Вдобавок тут огромное количество технических ништяков, которые нормальный интервьюер увидит, и вы проговорите про них оставшийся час:
- Hexagonal
- Асинхронная коммуникация
- Кафка та же самая
- Взаимодействие с нестабильными API
А в следующий раз я расскажу, как улучшить описание своих обязанностей, рассказывая о них через призму достижений
StringConcat - разработка без боли и сожалений
На собеседованиях гоняют по теории, потому что не знают, что ещё спрашивать! Как-то я прособеседовал 15 человек за неделю и понял, что соискатели сами виноваты в том, что их гоняют по дебрям теории и загадывают ребусы. Смотрите, в чём дело. Вот приходил…
Обещаная история, правда от Жени.
Однажды прихожу на обычный технический собес, меня встречают обычный разраб + менеджер типа тимлида. Задают обычные технические вопросы. Тимлид для вежливости спросил, чем я занимался до этого, я также из вежливости перечислил несколько проектов. Его заинтересовал один, и я начал рассказывать, как мы его запускали: выявляли потребности клиентов, проектировали, пилили, внедряли, решали трудности и как радовались первому контракту на миллион баксов! И это при том, что я был старшим бекенд-разрабом (да, кстати, если вы считаете, что разработка — это синоним к слову программирование, то у меня для вас плохие новости). Тимлид слушал, открыв рот, а к вечеру я получил оффер. Ни на один технический вопрос я так и не ответил, мне их просто не успели задать.
Почему так получилось
- Я рассказывал про свой опыт через призму достижений, а не «ну, месил там всякое и ел, что дают».
- На предварительных созвонах я задавал наводящие вопросы, а потому понимал, в каком состоянии находится команда нанимателя, какие у них есть проблемы. На очном собеседовании я рассказал о своём опыте решения таких проблем.
- Добавил немного циферок: сколько чего заработали, какой экономический эффект был нанесён.
- Рассказал, как брал инициативу и решал поступающие проблемы, а не просто ждал, пока мне нарежут таски. Это добавило мне очков.
В итоге мне не пришлось отвечать про кишочки JVM, которые я, конечно же, не помню, а получилось обойти духоту и получить оффер. Ничего сложного в этом нет, пользуйтесь.
Однажды прихожу на обычный технический собес, меня встречают обычный разраб + менеджер типа тимлида. Задают обычные технические вопросы. Тимлид для вежливости спросил, чем я занимался до этого, я также из вежливости перечислил несколько проектов. Его заинтересовал один, и я начал рассказывать, как мы его запускали: выявляли потребности клиентов, проектировали, пилили, внедряли, решали трудности и как радовались первому контракту на миллион баксов! И это при том, что я был старшим бекенд-разрабом (да, кстати, если вы считаете, что разработка — это синоним к слову программирование, то у меня для вас плохие новости). Тимлид слушал, открыв рот, а к вечеру я получил оффер. Ни на один технический вопрос я так и не ответил, мне их просто не успели задать.
Почему так получилось
- Я рассказывал про свой опыт через призму достижений, а не «ну, месил там всякое и ел, что дают».
- На предварительных созвонах я задавал наводящие вопросы, а потому понимал, в каком состоянии находится команда нанимателя, какие у них есть проблемы. На очном собеседовании я рассказал о своём опыте решения таких проблем.
- Добавил немного циферок: сколько чего заработали, какой экономический эффект был нанесён.
- Рассказал, как брал инициативу и решал поступающие проблемы, а не просто ждал, пока мне нарежут таски. Это добавило мне очков.
В итоге мне не пришлось отвечать про кишочки JVM, которые я, конечно же, не помню, а получилось обойти духоту и получить оффер. Ничего сложного в этом нет, пользуйтесь.
Telegram
StringConcat - разработка без боли и сожалений
На собеседованиях гоняют по теории, потому что не знают, что ещё спрашивать!
Как-то я прособеседовал 15 человек за неделю и понял, что соискатели сами виноваты в том, что их гоняют по дебрям теории и загадывают ребусы.
Смотрите, в чём дело.
Вот приходил…
Как-то я прособеседовал 15 человек за неделю и понял, что соискатели сами виноваты в том, что их гоняют по дебрям теории и загадывают ребусы.
Смотрите, в чём дело.
Вот приходил…
Про рак убивающий чатGPT
Пока нам обещают, что ИИ вот-вот заменит кожаных мешков, я последние несколько месяцев наблюдаю следующую тенденцию:
- В коде появились куски, сгенеренные жпт или чем-то подобным. При этом они такие упоротые, что диву даёшься. Их словно вставили неглядя, без оценки адекватности
- В требованиях тоже появились куски, сгенеренные чатом жпт, сходного качества
- То же самое наблюдаем в важных документах и презах. Понятно, что эти доки никто не читает обычно, но всё же…
Даже и не знаю, что и сказать. Вот вы вставляете код прямо из жпт? И если да, то что вами движет?
Пока нам обещают, что ИИ вот-вот заменит кожаных мешков, я последние несколько месяцев наблюдаю следующую тенденцию:
- В коде появились куски, сгенеренные жпт или чем-то подобным. При этом они такие упоротые, что диву даёшься. Их словно вставили неглядя, без оценки адекватности
- В требованиях тоже появились куски, сгенеренные чатом жпт, сходного качества
- То же самое наблюдаем в важных документах и презах. Понятно, что эти доки никто не читает обычно, но всё же…
Даже и не знаю, что и сказать. Вот вы вставляете код прямо из жпт? И если да, то что вами движет?
Собеседование — это продажа
Вот недавняя история про сабж.
Мы выбирали learning management system (LMS) для клиента. А такие продукты продают, как в кино, на очной презентации: вы оставляете почту на сайте, вам назначают встречу, и профессиональный продажник с вами общается. Все встречи проходят по одному сценарию. Сначала они узнают, что именно вам нужно, а потом рассказывают, как их уникальный продукт закрывает ваши индивидуальные потребности.
Но вот на той встрече всё было иначе. Пришёл японский дед и давай грузить фишками системы: как её можно устанавливать, какая она универсальная и гибкая, для всего вообще. Он даже не спросил, зачем она нам, а мы так и не поняли, делает ли система то, что нужно конкретно нам.
И тут меня осенило: ведь на собеседованиях мы делаем то же самое. Мы приходим и начинаем свой роковой танец с кейсами, не интересуясь, какую боль наниматели хотят закрыть. Хотя, очевидно, что прошлые подвиги могут быть нерелевантны текущей задаче.
Конечно, принимающая сторона тоже хороша: вместо того, чтобы рассказать о насущном, начинают загадывать ребусы и гонять по алгоритмам и дебрям кафок. Но их поведение мы изменить не можем, а своё — вполне.
Так что вот вам ключевой совет из нашего курса: ставьте себя на место работодателя. Попробуйте понять, какую боль он решает и покажите, как сможете решить эти проблемы на примерах того, как решали их раньше.
В следующем посте приведу пример, stay tuned.
Вот недавняя история про сабж.
Мы выбирали learning management system (LMS) для клиента. А такие продукты продают, как в кино, на очной презентации: вы оставляете почту на сайте, вам назначают встречу, и профессиональный продажник с вами общается. Все встречи проходят по одному сценарию. Сначала они узнают, что именно вам нужно, а потом рассказывают, как их уникальный продукт закрывает ваши индивидуальные потребности.
Но вот на той встрече всё было иначе. Пришёл японский дед и давай грузить фишками системы: как её можно устанавливать, какая она универсальная и гибкая, для всего вообще. Он даже не спросил, зачем она нам, а мы так и не поняли, делает ли система то, что нужно конкретно нам.
И тут меня осенило: ведь на собеседованиях мы делаем то же самое. Мы приходим и начинаем свой роковой танец с кейсами, не интересуясь, какую боль наниматели хотят закрыть. Хотя, очевидно, что прошлые подвиги могут быть нерелевантны текущей задаче.
Конечно, принимающая сторона тоже хороша: вместо того, чтобы рассказать о насущном, начинают загадывать ребусы и гонять по алгоритмам и дебрям кафок. Но их поведение мы изменить не можем, а своё — вполне.
Так что вот вам ключевой совет из нашего курса: ставьте себя на место работодателя. Попробуйте понять, какую боль он решает и покажите, как сможете решить эти проблемы на примерах того, как решали их раньше.
В следующем посте приведу пример, stay tuned.
Почему вы хотите работать у нас?
Продолжаем тему того, что фокусироваться нужно не на презентации своих самых выгодных сторон, а на решении проблем работодателя.
Вас спрашивают: почему вы хотите у нас работать?
И вы отвечаете:
- Мне понравилась ваша миссия
- У вас интересные задачи
- Мне нужно больше денег, а на текущем месте больше не дают
Все ответы плохи, кроме третьего: он ужасен. И все три ответа выдают вашу сосредоточенность на себе. В этих ответах нет пользы для компании.
Хороший ответ ложится во фреймворк:
Потому что вам нужно
В крайнем случае:
Потому что вам нужно X. Его я не делал, зато делал X’, X’’ и X’’’. Вот список моих достижений, которые прямо показывают, что я отлично справлюсь и с X
Так, вы из абстрактного разработчика превращаетесь в человека, который решит проблемы работодателя. А за решение конкретной боли можно и заплатить побольше.
Конечно, на интервью себя в деле не покажешь, но показать экспертизу вполне реально. Это мы учим на нашем курсе: как готовится к интервью и как отвечать на вопросы, чтобы не выглядеть японским дедом из предыдущего поста.
Курс запустим через 2 недели! Stay tuned!
Продолжаем тему того, что фокусироваться нужно не на презентации своих самых выгодных сторон, а на решении проблем работодателя.
Вас спрашивают: почему вы хотите у нас работать?
И вы отвечаете:
- Мне понравилась ваша миссия
- У вас интересные задачи
- Мне нужно больше денег, а на текущем месте больше не дают
Все ответы плохи, кроме третьего: он ужасен. И все три ответа выдают вашу сосредоточенность на себе. В этих ответах нет пользы для компании.
Хороший ответ ложится во фреймворк:
Потому что вам нужно
X, а я это уже делал, вот доказательства, и вам я это сделаю дешевле/лучше/быстрее другихВ крайнем случае:
Потому что вам нужно X. Его я не делал, зато делал X’, X’’ и X’’’. Вот список моих достижений, которые прямо показывают, что я отлично справлюсь и с X
Так, вы из абстрактного разработчика превращаетесь в человека, который решит проблемы работодателя. А за решение конкретной боли можно и заплатить побольше.
Конечно, на интервью себя в деле не покажешь, но показать экспертизу вполне реально. Это мы учим на нашем курсе: как готовится к интервью и как отвечать на вопросы, чтобы не выглядеть японским дедом из предыдущего поста.
Курс запустим через 2 недели! Stay tuned!
Моя коллега в Thoughtworks по имени Йю недавно пожаловалась, что уже на грани выгорания: клиент, с которым она работает, не принимает ни одно её изменение, словно в коде проекта нет проблем. Хуже того, он ещё жалуется в Thoughtworks, обвиняя Йю в саботаже. Мол, она спорит по пустякам, а не таски делает.
Я давно знаю Йю. Она — типичный Thoughtworker старой школы: мастер своего дела и перфекционист. Так что я решил выяснить, кто клиент.
А клиентом оказался очень старый и очень традиционный китайский банк. Там, ясное дело, верят, что у них идеальные процессы, которые можно не менять до конца времён. Каждый чих обсуждается специальным комитетом и проходит 5 уровней согласования. А главное, там уже работает два десятка специалистов Thoughtworks, они всем довольны и уходить не планируют.
Так что проблема не в клиенте и не в Йю. Проблема в несовпадении типа компании и мотивации человека.
Йю как лорд Варис из Игры престолов: стремится сделать всё правильно, изящно, умно и любой ценой. А клиент — образец восточной корпорации, для них главное, чтобы было по регламентам, стабильно и надёжно. Ни в том, ни в другом ничего плохого нет, просто корпорация хочет одного, а человек в ней — совсем другого.
В итоге я за 15 минут объяснил Йю матрицу типов корпораций и мотивации людей, как их отличать, а также почему другие ребята из Thoughtworks вполне довольны китайским банком. Йю стало легче жить, а банковская иммунная система прекратила считать её вирусом.
Здесь я эту матрицу рассказывать не буду, приходите на онлайн-встречу со мной и Евгением. Расскажем, что движет разными разработчиками и как выбрать компанию мечты.
Встреча в четверг, 27 июня, в 19:00 по Москве.
Записывайтесь у бота, он вам напомнит и скинет ссылку
Я давно знаю Йю. Она — типичный Thoughtworker старой школы: мастер своего дела и перфекционист. Так что я решил выяснить, кто клиент.
А клиентом оказался очень старый и очень традиционный китайский банк. Там, ясное дело, верят, что у них идеальные процессы, которые можно не менять до конца времён. Каждый чих обсуждается специальным комитетом и проходит 5 уровней согласования. А главное, там уже работает два десятка специалистов Thoughtworks, они всем довольны и уходить не планируют.
Так что проблема не в клиенте и не в Йю. Проблема в несовпадении типа компании и мотивации человека.
Йю как лорд Варис из Игры престолов: стремится сделать всё правильно, изящно, умно и любой ценой. А клиент — образец восточной корпорации, для них главное, чтобы было по регламентам, стабильно и надёжно. Ни в том, ни в другом ничего плохого нет, просто корпорация хочет одного, а человек в ней — совсем другого.
В итоге я за 15 минут объяснил Йю матрицу типов корпораций и мотивации людей, как их отличать, а также почему другие ребята из Thoughtworks вполне довольны китайским банком. Йю стало легче жить, а банковская иммунная система прекратила считать её вирусом.
Здесь я эту матрицу рассказывать не буду, приходите на онлайн-встречу со мной и Евгением. Расскажем, что движет разными разработчиками и как выбрать компанию мечты.
Встреча в четверг, 27 июня, в 19:00 по Москве.
Записывайтесь у бота, он вам напомнит и скинет ссылку
Telegram
StringConcat
Встреча по карьере в IT от разработчиков для разработчиков
Продолжение про мою коллегу Йю, которая как лорд Варис.
Матрица, которую мы с Йю разобрали, говорит, что если ты хочешь продвигать изменения — выбирай компании с типом управления «стартап». Там перемены принимают охотнее.
Но в стартапах есть свои риски. И я даже не про то, что они прогорают и банкротятся, а вы тратите несколько лет, за которые можно было карьеру построить в другом месте. Важнее, что не всё, что называется стартапом, является им по сути. Я имею в виду тип управления — то, как в компании смотрят на перемены, принимают решения и организуют команду.
Если не научиться определять тип управления, можно запросто попасть в молодую компанию, которая на словах стремится изменить мир, но на деле уже закостенела и стала микрокорпорацией с альянсами и старослужащими.
Как отличить графа Толстого ото льва простого — разбираем в этот четверг на онлайн-встрече.
Записывайтесь у бота, он вам напомнит и скинет ссылку
Матрица, которую мы с Йю разобрали, говорит, что если ты хочешь продвигать изменения — выбирай компании с типом управления «стартап». Там перемены принимают охотнее.
Но в стартапах есть свои риски. И я даже не про то, что они прогорают и банкротятся, а вы тратите несколько лет, за которые можно было карьеру построить в другом месте. Важнее, что не всё, что называется стартапом, является им по сути. Я имею в виду тип управления — то, как в компании смотрят на перемены, принимают решения и организуют команду.
Если не научиться определять тип управления, можно запросто попасть в молодую компанию, которая на словах стремится изменить мир, но на деле уже закостенела и стала микрокорпорацией с альянсами и старослужащими.
Как отличить графа Толстого ото льва простого — разбираем в этот четверг на онлайн-встрече.
Записывайтесь у бота, он вам напомнит и скинет ссылку
Telegram
StringConcat - разработка без боли и сожалений
Моя коллега в Thoughtworks по имени Йю недавно пожаловалась, что уже на грани выгорания: клиент, с которым она работает, не принимает ни одно её изменение, словно в коде проекта нет проблем. Хуже того, он ещё жалуется в Thoughtworks, обвиняя Йю в саботаже.…
Дружесская встреча уже через 3 часа! На повестке дня
— Какова ваша мотивация?
— Что вами движет?
— Что даёт удовлетворение от работы?
— Как использовать свои мотивы для построения карьеры?
Обо всём этом мы поговорим на открытом уроке из нашего нового курса «Как построить карьеру в IT». Приходите сегодня в 19:00 по Москве.
Регистрируйтесь!
— Какова ваша мотивация?
— Что вами движет?
— Что даёт удовлетворение от работы?
— Как использовать свои мотивы для построения карьеры?
Обо всём этом мы поговорим на открытом уроке из нашего нового курса «Как построить карьеру в IT». Приходите сегодня в 19:00 по Москве.
Регистрируйтесь!
Telegram
StringConcat
Встреча по карьере в IT от разработчиков для разработчиков
Самое ценное что я получил за 5 лет в Thoughtworks — это внутренние стандарты разработки. Называются они Sensible Defaults.
Стандарты описывают, как должен выглядеть любой проект TW и кто чем должен заниматься:
PM — служить команде разработки и устранять проблемы до их зрелости, а не колбаски в ганте рисовать
Аналитики — задавать неудобные вопросы заказчику и переводить ответы на язык бизнес-логики
Разработчики — использовать TDD, работать в парах и настроить деплой в прод ещё до кода
Почитайте, если вам интересно, чего там ещё такого, что позволяет TW чарджить консультантов в 2 раза дороже конкурентов. Благо теперь Sensible Defaults доступны всем желающим
Стандарты описывают, как должен выглядеть любой проект TW и кто чем должен заниматься:
PM — служить команде разработки и устранять проблемы до их зрелости, а не колбаски в ганте рисовать
Аналитики — задавать неудобные вопросы заказчику и переводить ответы на язык бизнес-логики
Разработчики — использовать TDD, работать в парах и настроить деплой в прод ещё до кода
Почитайте, если вам интересно, чего там ещё такого, что позволяет TW чарджить консультантов в 2 раза дороже конкурентов. Благо теперь Sensible Defaults доступны всем желающим
Thoughtworks
Sensible defaults
There's no one right way to build software — context is everything. But our sensible defaults provide a starting point for our teams: a set of initial assumptions that we know to be effective and useful. Check out the Sensible Defaults Playbook to learn more.
Мы с Женей планируем обсудить Sensible Defaults на стриме. Проголосуйте, если хотите поучаствовать
Anonymous Poll
67%
😍 Приду, хочу обсудить то, что ближе к разработке
18%
🧐 Приду, хочу поговорить о требованиях к PM, аналитикам и прочим архитекторам
15%
🤮 Не приду, не хочу
Встреча-обсуждение Sensible Defaults 15 Июля (ПН) 19:00
В следующий Понедельник, 15 Июля в 19:00 собираемся на стрим обсуждать Sensible Defaults: кодекс поведения четких разработчиков.
В этот раз начнем с разрабов, секьюрити и девопса
Формат: Встрерча в Zoom, бурное обсуждение. Лимит 1.5 часа, приносить свое пиво, чай, кофе. Приготовьтесь живо участвовать в обсуждении!
Записываться у бота
В следующий Понедельник, 15 Июля в 19:00 собираемся на стрим обсуждать Sensible Defaults: кодекс поведения четких разработчиков.
В этот раз начнем с разрабов, секьюрити и девопса
Формат: Встрерча в Zoom, бурное обсуждение. Лимит 1.5 часа, приносить свое пиво, чай, кофе. Приготовьтесь живо участвовать в обсуждении!
Записываться у бота
Telegram
StringConcat - разработка без боли и сожалений
Самое ценное что я получил за 5 лет в Thoughtworks — это внутренние стандарты разработки. Называются они Sensible Defaults.
Стандарты описывают, как должен выглядеть любой проект TW и кто чем должен заниматься:
PM — служить команде разработки и устранять…
Стандарты описывают, как должен выглядеть любой проект TW и кто чем должен заниматься:
PM — служить команде разработки и устранять…
Новый поток курса Разработка без боли и сожалений. стартует уже 26 июля!
- На нем детеально разбираем DDD на реальном коммерческом проекте,
- Разбираем как чистая Архитектура работает в настоящем приложени.
- На созвонах в Зуме разбираем сложные темы такие как TDD, построение CI
- Работаем с настоящим экпсертом на event storming’е
До 26 июля скида 20т.р.
Записываться тут!
По возникшим вопросам обращаться к @dubrova_a
Увидимся!
- На нем детеально разбираем DDD на реальном коммерческом проекте,
- Разбираем как чистая Архитектура работает в настоящем приложени.
- На созвонах в Зуме разбираем сложные темы такие как TDD, построение CI
- Работаем с настоящим экпсертом на event storming’е
До 26 июля скида 20т.р.
Записываться тут!
По возникшим вопросам обращаться к @dubrova_a
Увидимся!
howto.stringconcat.ru
Разработка и эксплуатация Enterprise-приложений без боли и сожалений
Паттерны поведения: суетолог
Из личных наблюдений за коллегами
Главная особенность. Когда что-то идёт не так, суетолог не разбирается в причинах и обстоятельствах, а сразу начинает паниковать, дергаться и наводить суету.
Проблема. Суетливые метания не помогают решать проблему, а лишь истощают внимание, накручивают вас и злят окружающих.
Пример 1. Человек написал код, и у него вдруг перестал проходить сквозной GUI-тест. В тесте написано: тут таймаут, кнопку не видим.
Но вместо того, чтобы посмотреть скриншот и зайти в приложение, начинается перезапуск тестов 1000 раз, попытки откатить код и т.д. без попыток понять, что происходит и в чем дело. А дело было в протухшем токене от внешней интеграции, что диагностируется за 10 секунд.
Пример 2. «А-а-а! Локальный стенд не работает» и те же самые телодвижения. А надо было всего лишь внимательно почитать лог запуска и в последней строке увидеть, что у докера закончилось место.
Противодействие. Если у вас что-то не получается, не запускается или не работает, просто отойдите на 10 минут от компьютера, подумайте как вы можете диагностировать проблему и вернитесь обратно. Сэкономите кучу времени себе и окружающим.
Из личных наблюдений за коллегами
Главная особенность. Когда что-то идёт не так, суетолог не разбирается в причинах и обстоятельствах, а сразу начинает паниковать, дергаться и наводить суету.
Проблема. Суетливые метания не помогают решать проблему, а лишь истощают внимание, накручивают вас и злят окружающих.
Пример 1. Человек написал код, и у него вдруг перестал проходить сквозной GUI-тест. В тесте написано: тут таймаут, кнопку не видим.
Но вместо того, чтобы посмотреть скриншот и зайти в приложение, начинается перезапуск тестов 1000 раз, попытки откатить код и т.д. без попыток понять, что происходит и в чем дело. А дело было в протухшем токене от внешней интеграции, что диагностируется за 10 секунд.
Пример 2. «А-а-а! Локальный стенд не работает» и те же самые телодвижения. А надо было всего лишь внимательно почитать лог запуска и в последней строке увидеть, что у докера закончилось место.
Противодействие. Если у вас что-то не получается, не запускается или не работает, просто отойдите на 10 минут от компьютера, подумайте как вы можете диагностировать проблему и вернитесь обратно. Сэкономите кучу времени себе и окружающим.
До Thoughtworks Сингапура докатился кризис, и меня сократили.
Реалити-шоу “Сможет ли Сережа найти работу за 2 месяца” начинается!
Через 2 месяца я обязан забрать детей из школы, сдать квартиру и покинуть Сингапур. Или найти новую работу. :)
Буду вести трансляцию в канале!
Впечатления пока следующие:
• Откликаться на вакансии – дело очень утомительное и бесполезное. Пока 0 собеседований. Как только вакансия открывается, в первый же день туда поступает более 100 заявок.
• Networking работает. Если видишь открытую вакансию и можешь найти хоть кого-то, кто может напрямую закинуть твоё резюме HR’у, то шансы попасть на собеседование возрастают на порядок (да, в 10 раз). А если вас могут ещё и порекомендовать, то это увеличивает шансы прийти на интервью практически до 100%.
Реалити-шоу “Сможет ли Сережа найти работу за 2 месяца” начинается!
Через 2 месяца я обязан забрать детей из школы, сдать квартиру и покинуть Сингапур. Или найти новую работу. :)
Буду вести трансляцию в канале!
Впечатления пока следующие:
• Откликаться на вакансии – дело очень утомительное и бесполезное. Пока 0 собеседований. Как только вакансия открывается, в первый же день туда поступает более 100 заявок.
• Networking работает. Если видишь открытую вакансию и можешь найти хоть кого-то, кто может напрямую закинуть твоё резюме HR’у, то шансы попасть на собеседование возрастают на порядок (да, в 10 раз). А если вас могут ещё и порекомендовать, то это увеличивает шансы прийти на интервью практически до 100%.
Forwarded from { между скобок } анонсы 📣 (Grisha Skobelev)
1 августа 19:00 по мск “Learning Domain-Driven Design Часть II. Тактический замысел (Глава 5-7) / Евгений Лукьянов”
Продолжаем разбор книжки по DDD. Переходим от стратегии к тактике: будет дан ответ на вопрос «Как проектировать программное обеспечение?». В главах 5–7 будут рассмотрены паттерны реализации бизнес-логики, позволяющие программному коду «говорить» на едином языке ограниченного контекста. В этих главах обсуждаются простые паттерны, такие как транзакционный сценарий и активная запись (глава 5), сложные паттерны, такие как модель предметной области (глава 6), и её расширение с учётом фактора времени (глава 7).
Помогать в обсуждение нам будет - Евгений Лукьянов 🔥 Архитектор ПО, практикующий адепт DDD. Ведет канал https://www.tg-me.com/StringConcat разработка без боли и сожалений/com.stringconcat
Подключайтесь в четверг в 19:00 к обсуждению в Zoom или к YouTube трансляции
А в комментариях к этому посту оставляйте свои вопросы, которые хотели бы задать Жене ⤵️
Продолжаем разбор книжки по DDD. Переходим от стратегии к тактике: будет дан ответ на вопрос «Как проектировать программное обеспечение?». В главах 5–7 будут рассмотрены паттерны реализации бизнес-логики, позволяющие программному коду «говорить» на едином языке ограниченного контекста. В этих главах обсуждаются простые паттерны, такие как транзакционный сценарий и активная запись (глава 5), сложные паттерны, такие как модель предметной области (глава 6), и её расширение с учётом фактора времени (глава 7).
Помогать в обсуждение нам будет - Евгений Лукьянов 🔥 Архитектор ПО, практикующий адепт DDD. Ведет канал https://www.tg-me.com/StringConcat разработка без боли и сожалений/com.stringconcat
Подключайтесь в четверг в 19:00 к обсуждению в Zoom или к YouTube трансляции
А в комментариях к этому посту оставляйте свои вопросы, которые хотели бы задать Жене ⤵️
StringConcat - разработка без боли и сожалений
1 августа 19:00 по мск “Learning Domain-Driven Design Часть II. Тактический замысел (Глава 5-7) / Евгений Лукьянов” Продолжаем разбор книжки по DDD. Переходим от стратегии к тактике: будет дан ответ на вопрос «Как проектировать программное обеспечение?».…
Для тех кто вчера не смог — по ссылке на ютуб доступна запись
YouTube
Learning Domain-Driven Design Часть II. Тактический замысел (Глава 5-7) / Евгений Лукьянов
#ddd #softwarearchitecture #softwareengineer
Продолжаем разбор книжки по DDD. Переходим от стратегии к тактике: будет дан ответ на вопрос «Как проектировать программное обеспечение?». В главах 5–7 будут рассмотрены паттерны реализации бизнес-логики, позволяющие…
Продолжаем разбор книжки по DDD. Переходим от стратегии к тактике: будет дан ответ на вопрос «Как проектировать программное обеспечение?». В главах 5–7 будут рассмотрены паттерны реализации бизнес-логики, позволяющие…
Мои наблюдения за обстановкой на мировом рынке. Субъективно, но непредвзято.
1 Звонил индус-HR, который 2 года назад пытался продать меня в одну компанию. Говорит, искать некого, работы нет, на хлеб не хватает. Предлагал свои услуги.
2. В чате русских экспатов в Гонконге бывший менеджер Яндекса готов заплатить 2000 $ за рекомендацию в местную компанию, если он туда устроится.
3. Француз думает переехать вместе с русской женой в Россию, чтобы получить разрешение на работу. Во Франции работу найти нереально.
4. Рекрутеры из Лондона радуются, что разрабов стало сильно проще искать. Соискатели теперь не просят офисы с массажистами, лишь бы хватало на жильё.
5. Товарищ из европейского Гугла с уровнем скилов «пройду собес не просыпаясь» переживает из-за недавних сокращений и чувствует себя не очень уверенно.
6. Знакомых в одной европейской продуктовой конторе постепенно заменяют на удалённых бангалорских индусов, оставляя старых экспертов только на самых критичных участках.
Конечно, это не объективная картина, но ещё 2 года назад такие истории звучали дико и смешно. А сегодня звучит обыденно.
Как думаете: отчего так, долго ли продлится и доберется ли тренд до России?
1 Звонил индус-HR, который 2 года назад пытался продать меня в одну компанию. Говорит, искать некого, работы нет, на хлеб не хватает. Предлагал свои услуги.
2. В чате русских экспатов в Гонконге бывший менеджер Яндекса готов заплатить 2000 $ за рекомендацию в местную компанию, если он туда устроится.
3. Француз думает переехать вместе с русской женой в Россию, чтобы получить разрешение на работу. Во Франции работу найти нереально.
4. Рекрутеры из Лондона радуются, что разрабов стало сильно проще искать. Соискатели теперь не просят офисы с массажистами, лишь бы хватало на жильё.
5. Товарищ из европейского Гугла с уровнем скилов «пройду собес не просыпаясь» переживает из-за недавних сокращений и чувствует себя не очень уверенно.
6. Знакомых в одной европейской продуктовой конторе постепенно заменяют на удалённых бангалорских индусов, оставляя старых экспертов только на самых критичных участках.
Конечно, это не объективная картина, но ещё 2 года назад такие истории звучали дико и смешно. А сегодня звучит обыденно.
Как думаете: отчего так, долго ли продлится и доберется ли тренд до России?